Partie 1 : Introduction
1. Avant-propos
1.1. Sur ce document
1.1.1. A qui est destiné ce document?
Les étudiants qui découvrent le langage, mes collègues enseignants qui cherchent un document de support à leur cours et d’exercice accessible, et … moi-même (pour organiser mes notes diverses)!
1.1.2. A qui n’est-il pas destiné?
Si vous appartenez à l’une de ces catégories, ce livre n’est pas pour vous :
1.1.3. Historique
Ce document est la compilation de plusieurs années d’enseignement de SysML depuis 2007, que ce soit :
-
au Master TI, de l’Université de Pau et des Pays de l’Adour (cours d’introduction avec mon collègue et ami Nicolas Belloir),
-
au Master Recherche SAID, de l’UPS (introduction),
-
au Master ICE de l’Université de Toulouse II - Le Mirail (introduction avec mon collègue et ami Pierre de Saqui Sannes),
-
au Master of Science de Göteborg, Suède (introduction réalisée par Nicolas Belloir),
-
à l’Universitad Autónoma de Guadalajara, au Mexique (40h de formation professionnelle aux employés de Continental),
-
ou plus récemment au Master DL-SI de l’UPS.
Vous trouverez en référence (cf. [refs]) les ouvrages et autres documents utilisés.
Je tiens à remercier mes collègues qui m’ont aidé dans mon entreprise :
-
Nicolas Belloir de l’Université de Pau et des Pays de l’Adour, Laurent Nonne de l’IUT de Blagnac et Karina Aguilar de l’Universitad Autónoma de Guadalajara;
-
mes collègues de SysML-France : Pascal Roques (PRFC), Agusti Canals (C-S) et Loïc Féjoz (RTaW);
-
mon maître d’AsciiDoc : Jean-Michel Inglebert.
1.2. Sur l’auteur
-
Professeur à l’Univesité de Toulouse
-
Co-fondateur de l’association SysML-France en 2009
-
Membre du comité éditorial de la revue Software and System Modeling journal depuis sa création en 2002
-
Membre du Steering Committee de la conférence ACM/IEEE MODELS depuis 2008
-
Enseignant en modélisation depuis 1995
-
Chef du département informatique de l’IUT de Blagnac de 2009 à 2012
-
Co-responsable de l’axe Systèmes Ambiants de l’IRIT
-
Marié, une (merveilleuse) fille
1.3. Comment lire ce document?
1.3.1. Version électronique
Ce document a été réalisé de manière à être lu de préférence dans sa version électronique, ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.
|
Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, mais n’hésitez pas à en consulter la version électronique! |
1.3.2. Conventions typographiques
J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :
-
des mises en formes particulières (e.g., NomDeBloc pour un élément de modèle),
-
des références bibliographiques, présentées en fin de document (cf. [refs]),
-
tous les flottants (figures, tableaux) sont listés à la suite de la table des matière,
-
les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons volontairement ces termes (e.g., Requirements).
Les figures, sauf mention contraire, ont été réalisées avec l’outil TOPCASED en français. Le titre des figures indique (entre parenthèses) un R pour les figures issues de Rhapsody et un UK pour les figures en anglais. Pour les conventions (de nommage notamment), cf. [conventions].
|
|
Les notes comme celles-ci sont utilisées pour indiquer des éléments intéressant pour la majorité des lecteurs. |
|
Ces notes indiquent des points importants qui réclament votre attention. |
|
Celles-ci concernent en général des points de détail et permettent "d’aller plus loin". |
|
Définition : Exemple (OMG SysML v1.3, p. 152)
Ces notes concernent des définitions tirées de la spécification SysML et sont donc précisément référencées. |
1.3.3. Pourquoi parler de "document"?
1.3.4. Utilisation et autres mentions légales
Dernière MAJ : 25/06/2013 - 18:48:34 CEST
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham.
La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert.
Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons.
licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.
N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.
1.4. Méthode pour cet ouvrage
C’est à l’heure du commencement qu’il faut tout particulièrement veiller à ce que les équilibres soient précis.
— Princesse Irulan
Mon approche pédagogique repose sur quelques principes, que j’ai essayé de mettre en oeuvre dans cet ouvrage :
- La répétition
-
Par exemple certains diagrammes sont abordés plusieurs fois (comme le diagramme paramétrique). Le lecteur pourra avoir une impression de redite par moment. Sauf erreur de ma part (toujours possible!), c’est volontaire. En général les répétitions vont en niveau de précision, de détails et de complexité croissant. Ces répétitions sont limitées dans la version livre de cet ouvrage (car toute longueur inutile a un coût dans ce cas).
- L’illustration
-
Dans la mesure du possible, j’essaye de donner des exemples aux principes énoncés. Vous trouverez donc plus d’exemples que de définitions.
- Le référencement
-
Les définitions ou autres affirmations sont tirées d’ouvrages de référence généralement citées.
- La "carte de base"
-
J’aime réaliser une "carte"
[voir aussi le concept de Mind Maps.]
qui sert à "placer" les différents concepts abordés. Il me semble que cela permet aux étudiants de raccrocher les nouveaux concepts aux précédents.
Aucune connaissance particulière d’UML n’est nécessaire, même si j’y fais référence à plusieurs endroits pour les étudiants qui connaissent cette notation (quasiment enseignée partout maintenant comme langage de modélisation). Il s’agit d’un parti pris prenant en compte plusieurs points :
2. C’est quoi SysML?
Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir.
2.1. Fiche d’identité
2.2. SysML, c’est…
- Un ensemble de 9 types de diagrammes
-
-
Diagrammes structuraux
-
Diagrammes de définition de blocs (bdd)
-
Diagrammes internes de blocs (ibd)
-
Diagrammes paramétriques (par)
-
Diagrammes de packages (pkg)
-
-
Diagrammes comportementaux
-
Diagrammes de séquence (sd)
-
Diagrammes d’activité (act)
-
Diagrammes de cas d’utilisation (uc)
-
Diagrammes d'états (stm)
-
-
Diagramme d’exigence (req)
-
- Un profil UML
-
C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML. Un exemple : le bloc qui n’est qu’une redéfinition de la classe.
- Une notation
-
Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.
2.3. SysML, ce n’est pas…
- Une méthode
-
En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.
- Un outil
-
Nous verrons en effet que SysML ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.
- Un raton laveur
-
C’est juste pour voir ceux qui suivent.
2.4. Références et liens utiles
Vous trouverez en fin d’ouvrage un ensemble de liens utiles (cf. [liens]) et de références (cf. [refs]). Sinon, vous pouvez aussi constatez les évolutions de l’intérêt pour SysML grâce aux "trends". Voici les dernières tendances au moment où nous écrivons ces lignes
[Ou bien utilisez les URLs comme http://www.google.fr/trends/explore#q=sysml.]
:
|
|
On y voit les journées SysML 2012 (Toulouse et Mulhouse). |
À noter également que l’OMG a réalisé en 2009 une enquête sur l’utilisation de SysML
[http://www.omgsysml.org/SysML_2009_RFI_Response_Summary-bone-cloutier.pdf]
dont voici deux extraits :
3. À propos du Bac STI2D
Si vous utilisez cet ouvrage dans le cadre du bac STI2D (Sciences et Technologies de l’Industrie et du Développement Durable) qui a introduit depuis 2011 la notation SysML au programme, nous donnons
ici des conseils sur l’utilisation de ce cours
[Je remercie au passage les collègues de Lycée rencontrés dans le cadre de SysML-France pour nos fructueuses discussions à ce sujet.]
.
L’objectif en STI2D n’est pas de former des spécialistes de SysML mais de permettre à tous d’apprendre une notation pour la modélisation de système qui se veut universelle. Il ne faut donc pas viser la complétude ou même demander trop de détails. La logique de la démarche de modélisation et l’importance de la communication devront primer.
|
|
A l’heure où nous écrivons ces lignes, il est également prévu de l’enseigner en classe prépa dès 2013. |
3.1. Utilisation pratique
Cet ouvrage est tout à fait utilisable dans le cadre des cours dispensés en STI2D. Seul un sous-ensemble des diagrammes de SysML a été retenu. Les élèves et les enseignants du bac STI2D pourront trouver dans ce document des éléments utiles sur ces diagrammes :
Ces 6 diagrammes sont tous traités dans cet ouvrage à un niveau qui devrait correspondre à l’utilisation qui en est faite en STI2D.
Ces 6 diagrammes servent trois objectifs principaux inscrits au programme et dont les élèves pourront également trouver des éléments de réflexion :
-
Modélisation des exigences (cf. [exigences])
-
Modélisation structurelle (cf. [structure])
-
Modélisation comportementale (cf. [comportement])
3.2. Pour aller plus loin
Les questions et exercices de fin de chapitres de la partie notation seront peut-être d’un niveau plus avancé pour servir véritablement d’exercices, mais pourront amener à une réflexion encadrée par l’enseignant.
Un blog récent recense les supports en liens avec STI2D : http://www.scoop.it/t/formation-sysml-sti2d.
4. Un exemple fil rouge
L’exemple de système qui sera modélisé tout au long de ce livre en guise d’exemple est l’exemple d’un système de gestion et de supervision de crise. Les détails sont donnés en annexe (cf. Annexes).
Il existe un certain nombre d’autres exemple complets :
-
Le radio-réveil de Pascal Roques [Roques2010], un exemple simpliste mais didactique qui a le mérite d'être déjà connu des modeleurs UML qui ont lu ses livres.
-
Le distilleur de [FMS], un exemple très complet et lui aussi très connu car beaucoup utilisé dans les tutoriels issus de l’OMG.
-
Le pacemaker de [SeeBook2012]
[Nous avons réalisé le chapitre d’introduction à SysML de cet ouvrage.]
, un exemple très récent et dont l’avantage est d'être traité selon plusieurs approches différentes et complémentaires (SysML, AADL et MARTE).
Les exemples complets ont le mérite de donner une vue d’ensemble des liens qui peuvent exister entre les différents diagrammes. On peut y voir comment ces diagrammes sont complémentaires les uns des autres. Ils sont en général plus réalistes que les diagrammes utilisés pour illustrer tel ou tel concept de la notation.
4.1. Enoncé
|
|
Cette étude de cas est tirée de Kienzle2010 |
Le système CMS (crash management system) est un système distribué de gestion d’accidents qui est responsable de la coordination et de la communication entre un coordinateur présent dans une caserne de pompiers (appelé FSC pour Fire Station Coordinator) et un autre présent dans un poste de police (appelé PSC pour Police Station Coordinator) afin de gérer une crise dans un délai raisonnable.
La communication interne entre les membres de la police (y compris le PSC) est en dehors du domaine qui nous intéresse ici (la gestion de crise). La même hypothèse s’applique aux communications internes ou avec des acteurs externes côté pompiers (y compris le FSC). Les informations concernant la crise ainsi que tout ce qui a trait aux tâches des coordinateurs sont mises à jour et maintenues pendant et après la crise.
Il n’existe pas de base de données centrale; caserne de pompiers et police ayant leur base de données respectives distinctes et seulement accessible aux autre à travers le système CMS. Chaque processus de coordination est donc en charge de l’ajout et la mise à jour des informations dans sa base de données respective.
CMS commence à fonctionner au moment où une crise donnée a été détectée et déclarée à la fois à la caserne de pompiers et au poste de police.
Toutes les caractéristiques des différents acteurs sont détaillées ci-dessous.
4.1.1. Coordinateur des pompiers (FSC)
Un FSC maintient le contrôle sur une situation de crise en communiquant avec le coordinateur du poste de police (PSC) ainsi que les pompiers.
Pour atteindre ses objectifs, les responsabilités d’un FSC sont les suivantes :
-
de déterminer où, quand et combien de camions de pompiers à envoyer,
-
de communiquer avec le PSC pour se présenter,
-
de garder le PSC informé en ce qui concerne la crise,
-
de proposer une stratégie pour traiter la crise,
-
parvenir à un accord avec le PSC sur la façon de procéder,
-
de recevoir des mises à jour concernant la crise côté pompiers, et
-
de rassembler et de diffuser des informations actualisées aux pompiers.
4.1.2. Pompiers
Un pompier agit sur ordres reçus du FSC et des fait des rapports au FSC. Par ailleurs, un pompier communique avec d’autres pompiers, des victimes et des témoins.
Les responsabilités d’un pompier sont les suivantes :
-
recevoir des demandes pour aller/revenir sur les lieux de la crise,
-
signaler sa position au FSC,
-
signaler les conditions de la crise au FSC et à tous les pompiers, et
-
communiquer avec les victimes et les témoins.
4.1.3. Coordinateur du poste de police (PSC)
Pour atteindre ses objectifs, un PSC effectue les mêmes activités que le FSC.
4.1.4. Agents de police
Les agents de police agissent sur ordres reçus du PSC. En outre, un agent de police communique avec d’autres policiers, des victimes et des témoins. Pour atteindre ses objectifs, un agent de police exerce les mêmes activités qu’un pompier en termes de communication avec son coordinateur.
4.1.5. Victimes (de la crise)
Une victime a été touchée par la crise et peut communiquer avec les policiers et les pompiers. Les responsabilités d’une victime sont :
-
de fournir des informations liées à la crise
-
de suivre les instructions de pompiers et de policiers.
4.1.6. Témoins (de la crise)
Un témoin a observé la crise et communique avec les policiers et les pompiers. Les responsabilités d’un témoin sont les suivantes :
-
de fournir des informations aux pompiers et les policiers, et
-
de suivre les instructions de pompiers et de policiers.
4.1.7. Informations complémentaires
Pour enrichir vos modèles, vous pouvez incorporer certains des besoins non-fonctionnels décrits ci-dessous.
Le système de gestion de crise doit montrer les suivants propriétés non-fonctionnelles :
|
|
La traduction a été principalement obtenue automatiquement, alors n’hésitez pas en cas de doutes à poser des questions! |
Disponibilité
-
Le système doit être en opération 24 heures par jour, tous les jours, sans interruption, pendant toute l’année, sauf pour un temps d’arrêt maximal de 2 heures tous les 30 jours pour la maintenance.
-
Le système doit récupérer dans un maximum de 30 secondes en cas d'échec.
-
L’entretien doit être reportée ou interrompue quand une crise est imminente sans affecter les capacités des systèmes.
Fiabilité
-
Le système ne doit pas dépasser un taux d'échec maximum de 0,001%.
-
Les unités mobiles sont en mesure de communiquer avec d’autres unités sur le site crise et le centre de contrôle, indépendamment des conditions d’emplacement, le terrain et la météo.
Persistance
-
Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les crises : type de crise, l’emplacement de la crise, rapport d’un témoin, emplacement du témoin, les données concernant les témoins, la durée de la crise, les ressources déployées, les victimes civiles, les stratégies utilisées, l’emplacement des équipes de secours sur la crise, journal des communications, et des décisions.
-
Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les ressources disponibles et déployés (à la fois en interne et en externe) : type de ressources (humaines ou équipement), la capacité, l'équipe de sauvetage, l’emplacement, l’heure estimée d’arrivée (ETA) sur le site crise.
-
Le système doit permettre le stockage, la mise à jour et l’accès à l’information suivante sur les stratégies de sortie de crise : type de crise, étapes pour résoudre la crise, la configuration des missions nécessaires, des liens vers d’autres stratégies, applications aux crises précédentes, et le taux de succès.
Sécurité
-
Le système doit définir des politiques d’accès pour les différentes catégories d’utilisateurs. La politique d’accès doit décrire les éléments et informations de chaque acteur peut ajouter, accéder et mettre à jour les informations.
-
Le système doit authentifier les utilisateurs sur la base des politiques d’accès lors de leur premier accès pour accéder aux éléments d’informations. Si un utilisateur reste inactif pendant 30 minutes ou plus, le système doit les obliger à se ré-authentifier.
-
Toutes les communications dans le système doit utiliser des canaux sécurisés conformes avec le cryptage AES-128 standard.
Mobilité
-
Les ressources de secours doivent pouvoir accéder à l’information sur les mouvements.
-
Le système fournit des informations de localisation utiles pour économiser les ressources.
-
Les ressources de secours doivent communiquer leur emplacement au centre de contrôle.
-
Le système doit avoir accès à des cartes détaillées, des données de terrain et les conditions météorologiques pour l’emplacement de crise et les routes qui y mènent.
Sécurité
-
Le système doit surveiller les émissions provenant du site crise pour déterminer les distances de fonctionnement sûres pour les ressources de sauvetage.
-
Le système doit surveiller les conditions météorologiques et le terrain sur le site de crise pour assurer la sécurité et le retrait des moyens de secours, et l'évacuation de civils, et les victimes.
-
Le système détermine un périmètre pour le site crise pour assurer la sécurité des civils et l'évacuation des victimes à une distance sûre.
-
Le système surveille les activités criminelles pour assurer la sécurité des moyens de secours, des civils et des blessés.
-
La sécurité du personnel de secours doit avoir la priorité absolue pour le système.
Adaptabilité
-
Le système doit recommander ou solliciter des ressources alternatives en cas d’indisponibilité ou l’insuffisance de ressources appropriées.
-
Le système doit être en mesure d’utiliser les canaux de communication de rechange en cas d’indisponibilité ou l’insuffisance des moyens existants.
-
Le système doit être en mesure de maintenir une communication efficace dans les zones de perturbation ou de bruit élevé sur le site crise.
Précision
-
Le système doit avoir accès aux données de la carte, le terrain et les conditions météorologiques avec une précision de 99%.
-
Le système doit fournir des informations à jour pour sauver les ressources.
-
Le système doit enregistrer des données sur la réception sans modifications.
-
La communication entre le système et les ressources de sauvetage doit avoir un facteur de détérioration maximum de 0,0001 pour 1000 km
Partie 2 : Ingénierie système
1. Introduction
La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
1.1. Points de vue
Dans un axe horizontal, j’ai différencié quatre grands points de vue :
- Requirements
-
Les exigences et leur prises en compte sont un éléments critique pour le succès du développement du système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de [reqs]) nous insisterons beaucoup sur cet aspect qui est souvent à l’origine de l’intérêt de SysML.
- Structure
-
La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de SysML qui pose le moins de problème aux débutants.
- Comportement
-
Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.
- Transverse
-
Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence entre les phases de développement ou entre les points de vue.
1.2. Phase de développement
Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :
- Organisation
-
Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.)
- Analyse
-
Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.
- Conception
-
Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)
- Implémentation
-
Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).
2. Différence avec l’ingénierie logicielle
Enseignant en informatique, je me retrouve souvent à enseigner SysML à des informaticiens. D’où ce petit exposé sur mon opinion de la différence entre les deux "mondes".
2.1. Une ingénierie plus ancienne
Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.
2.2. Des systèmes plus complexes
On parle de système complexe lorsque l’on a affaire à :
-
un ensemble d'éléments humains et matériels en relation avec :
-
de nombreux éléments technologiques (Informatique, Hydraulique, Electronique, …)
-
intégrés pour fournir des services (finalité du système) en fonction de leur environnement
-
interagissant entre eux et avec leur environnement
-
On parle aussi de Système de systèmes quand un système :
-
doit gérer les interactions entre ses parties (ou composantes)
-
assure un comportement prévu à l’avance
-
gère les comportements (de l’environnement) inatendus
2.3. Différents types d’analyse
Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible.
Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :
Pour arriver à combler le gap entre le système à développer et ses spécifications.
3. Normes et standards
Il existe un grand nombre de standards en Ingénierie Système. Cette section fera (bientôt) une revue de ces différents standards et organismes et de leur utilisation (IEEE, EIA, ISO, certification, NASA, INCOSE, AFIS, …).
Enfin, citons un rapport de 2010, le Rapport Potier, qui présente l'état des logiciels embarqués et qui sera utiles à ceux qui s’intéressent aux verrous technologiques liés à ce domaine.
L’Ingénierie Système génère beaucoup de documentation. Les processus de certification (par exemple dans l’aéronautique) sont encore basés sur des documents textuels.
4. Des documents aux modèles
Vue la complexité grandissante des systèmes, petit à petit cette ingénierie tente de passer d’une ingénierie centrée documents à une ingénierie centrée modèles. D’où l’importance de se poser la question des notations et langages pour réaliser et communiquer avec ces modèles (cf. [Notation]).
5. Les exigences
L’ingénierie des exigences est d’une importance capitale en Ingénierie Système. Nous renvoyons pour l’instant le lecteur au cours de Master qui précède ce cours.
6. L’architecture du système
Liens avec AADL, …
7. Le comportement du système
Liens avec la V&V
8. Méthodes et démarches
Everything should be made as simple as possible, but not simpler.
SysML n’est pas une méthode. En effet aucune démarche n’est imposée pour l’utilisation des diagrammes, l’ordre logique dans lesquels il vaut mieux les réaliser, etc. La spécification ne porte que sur la notation elle-même. D’où le pluriel dans le titre de cette section : il existe presque autant de méthodes que d’entreprise développant des systèmes. Nous nous contenterons de donner ici quelques heuristiques (cf. [methodo] pour la présentation de quelques méthodes bien identifiées) :
Un diagramme ne doit pas être considéré comme définitif. Il peut être complété alors que l’on traite un autre aspect de la modélisation (exemple classique : ajout d’un nouveau bloc lors de la réalisation d’un diagramme de séquence). Quelque soit la démarche adoptée elle doit être itérative et permettre de revenir sur les premières étapes.
Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. [Matrice]).
N’essayez pas de réaliser tous les diagrammes possibles pour votre système. Réalisez uniquement ceux qui sont utiles à votre cas particulier.
Partie 3 : La notation SysML
1. Pourquoi une nouvelle notation
A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.
— Bertrand Russell
Il existe une notation qui se veut "unifiée" pour les modèles : UML. Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :
-
UML 1.x était complètement inadaptée :
-
Principalement pour les systèmes d’information
-
Peu de liens entre les diagrammes
-
Peu de liens entre les modèles et les exigences
-
-
UML 2.x n’est pas beaucoup mieux si ce n’est :
-
Implication des ingénieurs systèmes pour sa définition
-
Introduction du diagramme de structure composite
-
En conclusion UML est une bonne base :
-
Standard De facto en génie logiciel
-
Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)
-
Stable et extensible (grâce notamment au mécanisme de profile)
-
Beaucoup d’outils disponibles
Mais…
-
Manque de certains concepts clés d’Ingénierie Système
-
Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de classe ou d'héritage par exemple)
-
Trop de diagrammes (13 sortes)
2. Introduction à SysML
2.1. Fiche d’identité
Voici à quoi pourrait ressembler la fiche d’identité de SysML :
2.2. Différence avec UML
La figure suivante, tirée de la spécification, résume bien les liens entre SysML et UML, à savoir que SysML reprend une partie seulement des concepts d’UML (appelée UML4SysML) en y ajoutant des concepts nouveaux.
2.3. Qui est "derrière"?
- Industrie
-
American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …
- Vendeurs d’outils
-
Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …
- Autres organisations
-
AP-233, INCOSE, Georgia Institute of Technology, AFIS, …
|
|
La liste complète des membres de l’OMG est accessible à l’URL : http://www.omg.org/cgi-bin/apps/membersearch.pl |
2.4. Organisation des différents diagrammes
|
|
Définition : Types de diagrammes (OMG SysML v1.3, p. 170)
SysML diagram kinds should have the following names or (abbreviations) as part of the heading… |
2.5. Différence entre modèle et dessin
SysML n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML. Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.
C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML
[Sauf bien sûr au brouillon ou sur un tableau, notamment quand on travaille en équipe.]
, mais d’utiliser des outils dédiés (cf. [Outils]).
Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :
| Requirements, cf. [reqs] | Structure, cf. [archi] | Comportement, cf. [behavior] | Transverse, cf. [transvers] | |
|---|---|---|---|---|
Organisation |
pkg |
pkg, bdd |
pkg |
|
Analyse, Conception, Implémentation |
req |
bdd, ibd, sd, par |
uc, sd, stm, act |
par |
3. Outils SysML
Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :
Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.
Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.
|
|
Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation. |
4. Cadre pour les diagrammes
Abordons quelques principes généraux de SysML, c’est à dire des éléments indépendant d’un diagramme en particulier :
-
Chaque diagramme SysML représente un élément de modélisation
-
Chaque diagramme SysML doit être inclus dans un cadre (Diagram Frame)
-
L’entête du cadre, appelé cartouche, indique les informations sur le diagramme :
-
le type de diagramme (req, act, bdd, ibd, stm, etc.)
-
le type d'élément (package, block, activity, etc.)
-
le nom de l'élément
-
le nom du diagramme ou de la vue
-
Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un package, nommé "Context".
5. Organisation
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
5.1. Fondements
On abordera :
-
Le Package Diagram
-
Les différent types de packages
-
Les organisations possibles
-
La notion de Namespaces
-
Les Dependencies
5.2. Le Package Diagram
Le diagramme de paquetage permet de représenter l’organisation des modèles en paquetages.
-
Il est identique à UML, et classique pour les développeurs (java notamment)
-
Il permet d’organiser les modèles en créant un espace de nommage (cf [namespace])
Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]) :
-
hiérarchie "système" (e.g., entreprise, système, composant)
-
types de diagrammes (e.g., besoins, structure, comportements)
-
par points de vue
-
etc.
5.3. Les différent types de packages
Il existe plusieurs types de package :
- models
-
un package "top-level" dans une hiérarchie de packages
- packages
-
le type le plus classique : un ensemble d'éléments de modèles
- model librairies
-
un package prévu pour être réutilisé (importé) par d’autres éléments
- views
-
un package spécial pour représenter les points de vue
|
|
Un point de vue (viewpoint) est utilisé pour matérialiser une perspective particulière de modélisation. Il possède des propriétés standardisés (concerns, language, purpose, etc.) et permettent d’indiquer qu’une vue (un packetage particulier, stéréotypé <<view>>) est conforme (dépendance <<conform>>) à un point de vue. |
5.4. Les organisations possibles
Les modèles peuvent être organisés selon toutes sortes de considération :
-
par hiérarchie "système" (e.g., entreprise, système, composant, …)
-
par types de diagrammes (e.g., besoins, structure, comportements, …)
-
par cycle de vie (e.g., analyse, conception, …)
-
par équipes (e.g., architectes, [IPT], …)
-
par points de vue (e.g., sécurité, performance, …)
-
etc.
|
|
L’outil TOPCASED propose, lors de la création d’un premier modèle, de créer une organisation "type" par défaut.
|
5.5. La notion de Namespaces
Un package permet de créer un espace de nommage pour tous les éléments qu’il contient. Ainsi, dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.
|
|
Définition : Namespace (OMG SysML v1.3, p. 23)
The package defines a namespace for the packageable elements. |
Pour éviter toute ambiguité, on peut utiliser pour les éléments de modèles leur nom complet (Qualified name), c’est à dire le nom de l'élément préfixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).
|
|
Dans les outils SysML, il faut souvent demander explicitement à voir les noms complets (Qualified names) des éléments (la plupart du temps dans les options graphiques). |
5.6. Les dépendances
Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :
- Dependency
-
une dépendance "générale", non précisée,
représentée par une simple flèche pointillée -----> - Use
-
l'élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype <<use>> - Refine
-
l'élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<refine>> - Realization
-
l'élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<realize>> - Allocation
-
l'élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype <<allocate>>
5.7. En résumé
SysML propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’UML. Ces mécanismes seront plus faciles à comprendre au travers de leur utilisation concrète dans la suite.
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
package |
package |
package |
dependencies |
… |
5.8. Questions de révision
-
Quels sont les 5 types de dépendances entre packageable elements ?
-
À quoi cela peut-il servir de définir les dépendances (donnez des exemples concrets) ?
6. Les exigences
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
6.1. Fondements
On abordera :
-
L’organization des Requirements
-
Les Requirements properties
-
Les Requirements links
-
Les Requirements Diagrams
-
Les considérations sur la traçabilité
-
Annotations des Requirements
-
Les Use Case Diagrams (scénarios)
|
|
L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation système. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFIS ([REQ2012]). |
6.2. L’organisation des Requirements
Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.
6.2.1. Différents types d’organisation
L’ingénierie des exigences aboutit généralement à une liste organisée d’exigences, que ce soit en terme de fonctionnelles/non fonctionnelles, de prioritaires/secondaires, etc. Le principal support de SysML à cette organisation, outre la possibilité de les annoter (cf. section Stéréotyper les exigences), consiste à utiliser les packages.
Plusieurs types d’organisations sont possibles :
-
Par niveau d’abstraction
-
Besoins généraux (en lien avec les use cases par exemple)
-
Besoins techniques (en lien avec les éléments de conception)
-
-
Par point de vue
-
Besoins principaux (en lien avec les use cases)
-
Besoins spécifiques :
-
Fonctionnels
-
Marketing
-
Environnementaux
-
Business
-
…
-
-
-
etc.
6.2.2. Tableaux de Requirements
Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.
|
|
Définition : Namespace (OMG SysML v1.3, p. 145)
The tabular format is used to represent the requirements, their properties and relationships… |
6.3. Les Requirements properties
Il est possible d’indiquer un certain nombre de propriétés sur un requirement :
-
priority (high, low, …)
-
source (stakeolder, law, technical, …)
-
risk (high, low, …)
-
status (proposed, aproved, …)
-
verification method (analysis, tests, …)
6.4. Les Requirements links
Les principales relations entre requirement sont :
- Containment
-
pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–)
- Refinement
-
pour décrire un ajout de précision (<<refine>>)
- Derivation
-
pour indiquer une différence de niveau d’abstraction (<<deriveReqt>>), par exemple entre un système et un de ses sous-systèmes
|
|
Lorsqu’un cas d’utilisation possède plusieurs cas <<refine>> qui pointent vers lui, on considère que ces différents cas sont des options possibles de raffinement (cf. [conventions]). |
Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons dans la partie transverse.
6.5. Les Requirements Diagrams
Voici un exemple de req un peu plus étoffé, tiré de http://www.uml-sysml.org/sysml (voir aussi [rationale]) :
6.6. Stéréotyper les Requirements
Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :
-
<<interfaceRequirement>>, <<physicalRequirement>>, …
-
<<FunctionalRequirement>>, <<nonFunctionalRequirement>>
6.7. Annotations des Requirements
Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).
6.8. Les considérations sur la traçabilité
Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci sera abordé dans la partie [transvers].
|
|
En général chaque requirement devrait être relié à au moins un use case (et vice-versa!). |
6.9. Les Use Case Diagrams (scénarios)
Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.
Ce diagramme est exactement identique à celui d’UML.
|
|
Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs. |
6.10. En résumé
Les exigences sont très importantes en ingénierie système, plus en tout cas qu’en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML.
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
⊕–, <<deriveReqt>> |
|||
Analyse |
<<satisfy>>, <<refine>> |
<<satisfy>> entre reqs et UC |
<<refine>> |
|
Conception |
<<allocate>> |
|||
Implémentation |
<<satisfy>>, <<verify>> |
En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. [sysmod]).
6.11. Questions de révision
-
Quelles sont les différences entre besoins et exigences ?
-
En quoi les cas d’utilisation sont-ils complémentaires des exigences?
-
Quelle est la différence entre un package de type model et un package de type package?
7. L’architecture du système
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
7.1. Fondements
On abordera :
-
l’organisation du système et des modèles
-
les Block Definition Diagrams
-
les Internal Block Diagrams
-
les Parametric Diagrams (pour les contraintes physiques)
-
les Sequence Diagrams (diagramme de séquence système)
7.2. Organisation du système et des modèles
En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation (cf. [package]).
Pour l’organisation du système, on trouve le plus souvent :
-
un diagramme décrivant le contexte (le système dans son environnement), décrit dans un block definition diagram (cf. [contextebdd])
-
un diagramme décrivant les éléments internes principaux du système, décrit dans un internal block diagram
7.3. Block Definition Diagrams
7.3.1. Principes de base
Un bdd peut représenter :
-
un package
-
un bloc
-
un bloc de contrainte (constraint block)
Un diagramme de bloc décrit les relations entre les blocs (compositions, généralisations, …). Ce diagramme utilise les mêmes éléments que le diagramme de classe UML.
Un bloc est constitué d’un certain nombre de compartiments (Compartments) :
- Properties
-
Equivalent UML des propriétés (e.g., attributs).
- Operations
-
Les méthodes supportées par les instances du bloc.
- Constraints
-
Les contraintes (cf. [contraintes])
- Allocations
-
Les allocations (cf. [transvers])
- Requirements
-
Les exigences liées à ce bloc.
- User defined
-
On peut définir ses propres compartiments.
7.3.2. Propriétés
On peut différencier 4 types de propriétés d’un bloc :
- value properties
-
Des caractéristiques (quantifiables), aussi appelées simplement values
- parts
-
Les éléments qui composent le bloc (cf. [ibd])
- references
-
Les éléments auquel le bloc a accès (via des associations ou des agrégations)
- constraint properties
-
Les contraintes que doivent respecter les propriétés (nous les verrons plus en détail, cf. [param]).
|
|
Les values sont ce qui se rapproche le plus des attributs de classes UML. |
7.3.3. Value Types
Pour associer un type aux valeurs, SysML propose de définir des Value Types.
7.3.4. Associations entre blocs
Il existe deux types de relations entre blocs :
-
l’association (y compris l’agrégation et la composition)
-
la généralisation/spécialisation
Ces deux types de relations, bien connues en UML, permettent de matérialiser les liens qui existent entre les éléments du système. Avant d’aborder les associations, il est important de différencier la description d'éléments structurels sous la forme d’un bloc (au travers d’un bdd par exemple) et ces éléments pris individuellement. Ces derniers sont des instances individuelles du même bloc. Cette notion, très présente dans les approches orientées objets est souvent plus ardue à appréhender pour les ingénieurs systèmes. Il faut bien comprendre que la modélisation d’un bloc consiste à représenter l’ensemble des éléments qui caractérisent tout une série d’objets (des moteurs, des pompes, des données, etc.). Il serait fastidieux de les représenter tous (individuellement), et c’est donc leur "signature" que l’on représente. C’est pour cela qu’un bloc n’est pas un élément physique, mais simplement sa représentation, tandis qu’une instance de ce bloc représentera elle cet élément physique. C’est le cas notamment des participants d’un diagramme de séquence ou encore des parties d’un composé, qui sont des instances et non des blocs.
Association
Une association est un ensemble de liens permanents existant entre les instances de deux ou plusieurs blocs. On dira qu’une association lie plusieurs blocs ou que les blocs participent à l’association.
Une association possède plusieurs propriétés :
- Dimension d’une association
-
Nombre de blocs mis en jeu par l’association
(binaire : 2, ternaire : 3, n-aire : n)
|
|
Exemple d’association binaire
Soient les bloc Fournisseurs et Produits. On veut indiquer quels sont les produits susceptibles d’être fournis par chaque fournisseur et quels sont les fournisseurs susceptibles de fournir chaque produit.
|
- Nom d’une association
-
Afin de clarifier les informations, il est important de nommer les associations.
Il existe trois façons de nommer une association :-
un verbe à l’infinitif (e.g., Fournir)
-
un verbe conjugué avec un sens de lecture : Fournit > ou < Est fourni par
-
un rôle (placé à une extrémité de l’association)
-
- Cardinalité
-
Indique à combien d’instances minimum et maximum du bloc d’en face est lié toute instance du bloc de départ. Elle est représentée par un couple (M..N).
|
|
Attention, dans une cardinalité M..N, M doit toujours être inférieur ou égal à N. Exemple : 3..10. |
Vers le code : que signifie vraiment une association?
En terme de logiciel, une association représente une contrainte sur la suite du développement : que ce soit un code (en langage orienté objet la plupart du temps) ou une base de donnée.
Pour reprendre l’exemple précédent, cela signifie concrètement au niveau d’un code par exemple que depuis une variable Produits on doit être capable d’accéder à une variable (correspondante) de type tableau (ou liste, ou …) de Fournisseurs.
Ce qui peut donner en java :